home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 19 / CU Amiga Magazine's Super CD-ROM 19 (1998)(EMAP Images)(GB)[!][issue 1998-02].iso / CUCD / Online / RFCs / rfc / rfc2221.txt < prev    next >
Text File  |  1997-11-11  |  9KB  |  284 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           M. Gahrns
  8. Request for Comments: 2221                                      Microsoft
  9. Category: Standards Track                                    October 1997
  10.  
  11.  
  12.                          IMAP4 Login Referrals
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. Copyright Notice
  23.  
  24.    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  25.  
  26. 1. Abstract
  27.  
  28.    When dealing with large amounts of users and many IMAP4 [RFC-2060]
  29.    servers, it is often necessary to move users from one IMAP4 server to
  30.    another.  For example, hardware failures or organizational changes
  31.    may dictate such a move.
  32.  
  33.    Login referrals allow clients to transparently connect to an
  34.    alternate IMAP4 server, if their home IMAP4 server has changed.
  35.  
  36.    A referral mechanism can provide efficiencies over the alternative
  37.    'proxy method', in which the local IMAP4 server contacts the remote
  38.    server on behalf of the client, and then transfers the data from the
  39.    remote server to itself, and then on to the client.  The referral
  40.    mechanism's direct client connection to the remote server is often a
  41.    more efficient use of bandwidth, and does not require the local
  42.    server to impersonate the client when authenticating to the remote
  43.    server.
  44.  
  45. 2. Conventions used in this document
  46.  
  47.    In examples, "C:" and "S:" indicate lines sent by the client and
  48.    server respectively.
  49.  
  50.    A home server, is an IMAP4 server that contains the user's inbox.
  51.  
  52.    A remote server is a server that contains remote mailboxes.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Gahrns                      Standards Track                     [Page 1]
  59.  
  60. RFC 2221                 IMAP4 Login Referrals              October 1997
  61.  
  62.  
  63.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  64.    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
  65.    document are to be interpreted as described in [RFC-2119].
  66.  
  67. 3. Introduction and Overview
  68.  
  69.    IMAP4 servers that support this extension MUST list the keyword
  70.    LOGIN-REFERRALS in their CAPABILITY response.  No client action is
  71.    needed to invoke the LOGIN-REFERRALS capability in a server.
  72.  
  73.    A LOGIN-REFERRALS capable IMAP4 server SHOULD NOT return a referral
  74.    to a server that will return a referral. A client MUST NOT follow
  75.    more than 10 levels of referral without consulting the user.
  76.  
  77.    A LOGIN-REFERRALS response code MUST contain as an argument a valid
  78.    IMAP server URL as defined in [IMAP-URL].
  79.  
  80.    A home server referral consists of either a tagged NO or OK, or an
  81.    untagged BYE response that contains a LOGIN-REFERRALS response code.
  82.  
  83.    Example: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/] Remote Server
  84.  
  85.    NOTE: user;AUTH=* is specified as required by [IMAP-URL] to avoid a
  86.    client falling back to anonymous login.
  87.  
  88. 4. Home Server Referrals
  89.  
  90.    A home server referral may be returned in response to an AUTHENTICATE
  91.    or LOGIN command, or it may appear in the connection startup banner.
  92.    If a server returns a home server referral in a tagged NO response,
  93.    that server does not contain any mailboxes that are accessible to the
  94.    user.  If a server returns a home server referral in a tagged OK
  95.    response, it indicates that the user's personal mailboxes are
  96.    elsewhere, but the server contains public mailboxes which are
  97.    readable by the user.  After receiving a home server referral, the
  98.    client can not make any assumptions as to whether this was a
  99.    permanent or temporary move of the user.
  100.  
  101. 4.1.  LOGIN and AUTHENTICATE Referrals
  102.  
  103.    An IMAP4 server MAY respond to a LOGIN or AUTHENTICATE command with a
  104.    home server referral if it wishes to direct the user to another IMAP4
  105.    server.
  106.  
  107.    Example:  C: A001 LOGIN MIKE PASSWORD
  108.              S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified user
  109.                      is invalid on this server. Try SERVER2.
  110.  
  111.  
  112.  
  113.  
  114. Gahrns                      Standards Track                     [Page 2]
  115.  
  116. RFC 2221                 IMAP4 Login Referrals              October 1997
  117.  
  118.  
  119.    Example:  C: A001 LOGIN MATTHEW PASSWORD
  120.              S: A001 OK [REFERRAL IMAP://MATTHEW@SERVER2/] Specified
  121.                      user's personal mailboxes located on Server2, but
  122.                      public mailboxes are available.
  123.  
  124.    Example:  C: A001 AUTHENTICATE GSSAPI
  125.              <authentication exchange>
  126.              S: A001 NO [REFERRAL IMAP://user;AUTH=GSSAPI@SERVER2/]
  127.                      Specified user is invalid on this server. Try
  128.                      SERVER2.
  129.  
  130. 4.2. BYE at connection startup referral
  131.  
  132.    An IMAP4 server MAY respond with an untagged BYE and a REFERRAL
  133.    response code that contains an IMAP URL to a home server if it is not
  134.    willing to accept connections and wishes to direct the client to
  135.    another IMAP4 server.
  136.  
  137.    Example:  S: * BYE [REFERRAL IMAP://user;AUTH=*@SERVER2/] Server not
  138.                   accepting connections.  Try SERVER2
  139.  
  140. 5. Formal Syntax
  141.  
  142.    The following syntax specification uses the augmented Backus-Naur
  143.    Form (BNF) as described in [ABNF].
  144.  
  145.    This amends the "resp_text_code" element of the IMAP4 grammar
  146.    described in [RFC-2060]
  147.  
  148.    resp_text_code =/ "REFERRAL" SPACE <imapurl>
  149.       ; See [IMAP-URL] for definition of <imapurl>
  150.       ; See [RFC-2060] for base definition of resp_text_code
  151.  
  152. 6. Security Considerations
  153.  
  154.    The IMAP4 login referral mechanism makes use of IMAP URLs, and as
  155.    such, have the same security considerations as general internet URLs
  156.    [RFC-1738], and in particular IMAP URLs [IMAP-URL].
  157.  
  158.    A server MUST NOT give a login referral if authentication for that
  159.    user fails. This is to avoid revealing information about the user's
  160.    account to an unauthorized user.
  161.  
  162.    With the LOGIN-REFERRALS capability, it is potentially easier to
  163.    write a rogue 'password catching' server that collects login data and
  164.    then refers the client to their actual IMAP4 server.  Although
  165.    referrals reduce the effort to write such a server, the referral
  166.    response makes detection of the intrusion easier.
  167.  
  168.  
  169.  
  170. Gahrns                      Standards Track                     [Page 3]
  171.  
  172. RFC 2221                 IMAP4 Login Referrals              October 1997
  173.  
  174.  
  175. 7. References
  176.  
  177.    [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
  178.    4rev1", RFC 2060, December 1996.
  179.  
  180.    [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft,
  181.    September 1997.
  182.  
  183.    [RFC-1738], Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
  184.    Resource Locators  (URL)", RFC 1738, December 1994.
  185.  
  186.    [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
  187.    Requirement Levels", RFC 2119, March 1997.
  188.  
  189.    [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
  190.    Syntax Specifications: ABNF", Work in Progress.
  191.  
  192. 8.  Acknowledgments
  193.  
  194.    Many valuable suggestions were received from private discussions and
  195.    the IMAP4 mailing list.  In particular, Raymond Cheng, Mark Crispin,
  196.    Mark Keasling Chris Newman and Larry Osterman made significant
  197.    contributions to this document.
  198.  
  199. 9. Author's Address
  200.  
  201.    Mike Gahrns
  202.    Microsoft
  203.    One Microsoft Way
  204.    Redmond, WA, 98072
  205.  
  206.    Phone: (206) 936-9833
  207.    EMail: mikega@microsoft.com
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Gahrns                      Standards Track                     [Page 4]
  227.  
  228. RFC 2221                 IMAP4 Login Referrals              October 1997
  229.  
  230.  
  231. 10.  Full Copyright Statement
  232.  
  233.    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  234.  
  235.    This document and translations of it may be copied and furnished to
  236.    others, and derivative works that comment on or otherwise explain it
  237.    or assist in its implmentation may be prepared, copied, published
  238.    andand distributed, in whole or in part, without restriction of any
  239.    kind, provided that the above copyright notice and this paragraph are
  240.    included on all such copies and derivative works.  However, this
  241.    document itself may not be modified in any way, such as by removing
  242.    the copyright notice or references to the Internet Society or other
  243.    Internet organizations, except as needed for the purpose of
  244.    developing Internet standards in which case the procedures for
  245.    copyrights defined in the Internet Standards process must be
  246.    followed, or as required to translate it into languages other than
  247.    English.
  248.  
  249.    The limited permissions granted above are perpetual and will not be
  250.    revoked by the Internet Society or its successors or assigns.
  251.  
  252.    This document and the information contained herein is provided on an
  253.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  254.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  255.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  256.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  257.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Gahrns                      Standards Track                     [Page 5]
  283.  
  284.